Base Test is a reusable parent class used in Selenium automation frameworks to centralize common test setup and cleanup operations. Instead of creating WebDriver initialization, browser configuration, URL navigation, and browser closing logic in every test class, these common operations can be placed inside a BaseTest class.
Test classes can then extend the BaseTest class and directly use the initialized WebDriver. This reduces duplicate code, improves maintainability, and provides a consistent test execution structure. A BaseTest class is commonly combined with TestNG lifecycle annotations such as @BeforeMethod, @AfterMethod, @BeforeClass, and @AfterClass. :contentReference[oaicite:0]{index=0}
In a Selenium framework, the BaseTest generally acts as the common foundation between the test classes, WebDriver management, Page Object Model, configuration, reporting, screenshots, and other reusable framework components.
Course Resource: Selenium Training | Register for Course Demo
A BaseTest is a parent or superclass that contains common functionality required by multiple automated test classes.
For example, if an automation project contains 50 test classes and every test requires a browser to be opened before execution and closed after execution, placing this logic in every test class would create unnecessary duplication.
Instead, the common browser lifecycle can be implemented once in BaseTest.
BaseTest
|
+-- WebDriver initialization
|
+-- Browser configuration
|
+-- Application URL
|
+-- Common setup
|
+-- Common cleanup
|
+-- Screenshot handling
|
+-- Configuration
|
+-- Logging / Reporting
|
+-- Test Classes
BaseTest is important because it provides a centralized location for common automation functionality.
The basic relationship between BaseTest and test classes is inheritance.
BaseTest
|
|-- LoginTest
|
|-- SearchTest
|
|-- RegistrationTest
|
|-- CheckoutTest
|
|-- ProfileTest
Each test class extends BaseTest and inherits the common functionality.
public class LoginTest extends BaseTest {
}
public class SearchTest extends BaseTest {
}
public class CheckoutTest extends BaseTest {
}
A simple BaseTest can initialize Chrome before every test method and close the browser after the test completes.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
driver.manage().window().maximize();
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
The protected WebDriver allows child test classes to access the driver while keeping the field hidden from unrelated classes.
@BeforeMethod is a TestNG configuration annotation that runs before each test method. It is commonly used in BaseTest to create a fresh browser session for every test.
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
}
For example, if a class contains three test methods:
@Test
public void testLogin() {
}
@Test
public void testSearch() {
}
@Test
public void testCheckout() {
}
The conceptual execution is:
setUp()
|
testLogin()
|
tearDown()
setUp()
|
testSearch()
|
tearDown()
setUp()
|
testCheckout()
|
tearDown()
@AfterMethod executes after each TestNG test method. It is commonly used to close the browser and release WebDriver resources.
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
Using driver.quit() closes the browser session and associated browser windows.
In a BaseTest class, WebDriver is commonly declared as protected.
protected WebDriver driver;This allows classes that extend BaseTest to access the driver directly.
public class LoginTest extends BaseTest {
@Test
public void loginTest() {
driver.get("https://example.com/login");
}
}
The test does not need to create another WebDriver instance because it inherits the driver from BaseTest.
The BaseTest can also navigate to the application URL during setup.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com");
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
Every test that extends BaseTest will start with the application already opened.
A test class can extend BaseTest and focus only on the actual test scenario.
import org.testng.Assert;
import org.testng.annotations.Test;
public class LoginTest extends BaseTest {
@Test
public void verifyLoginPage() {
driver.get("https://example.com/login");
String title = driver.getTitle();
Assert.assertTrue(
title.contains("Login")
);
}
}
The browser setup and cleanup remain inside BaseTest while the test class contains the validation logic.
A single BaseTest can be reused by many test classes.
public class LoginTest extends BaseTest {
@Test
public void loginTest() {
driver.get("https://example.com/login");
}
}
public class SearchTest extends BaseTest {
@Test
public void searchTest() {
driver.get("https://example.com/search");
}
}
public class CheckoutTest extends BaseTest {
@Test
public void checkoutTest() {
driver.get("https://example.com/checkout");
}
}
This approach keeps browser lifecycle management centralized.
TestNG starts
|
v
Test class extends BaseTest
|
v
@BeforeMethod
|
v
Create WebDriver
|
v
Configure browser
|
v
Open application
|
v
@Test method
|
v
Assertions
|
v
@AfterMethod
|
v
driver.quit()
|
v
Test completed
A BaseTest can centralize browser configuration such as window size, browser options, and other common WebDriver settings.
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.manage().deleteAllCookies();
}
Centralizing these settings prevents each test class from implementing the same browser configuration.
ChromeOptions can be configured in BaseTest when browser-specific settings are required.
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
@BeforeMethod
public void setUp() {
ChromeOptions options = new ChromeOptions();
options.addArguments("--start-maximized");
driver = new ChromeDriver(options);
}
Common options can be maintained centrally and reused by all test classes.
The BaseTest can also be designed for Firefox.
import org.openqa.selenium.firefox.FirefoxDriver;
@BeforeMethod
public void setUp() {
driver = new FirefoxDriver();
driver.manage().window().maximize();
}
For multi-browser frameworks, the browser creation logic is usually moved into a DriverFactory rather than placing every browser implementation directly inside BaseTest.
TestNG parameters can be used to select a browser dynamically.
@Parameters("browser")
@BeforeMethod
public void setUp(String browser) {
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
} else {
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
This allows the same test framework to execute against different browsers without changing the test classes.
The @Optional annotation can provide a default value when a TestNG parameter is not supplied.
@Parameters("browser")
@BeforeMethod
public void setUp(
@Optional("chrome") String browser) {
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
}
}
This can make local execution easier when no browser parameter is supplied through TestNG XML.
A browser parameter can be supplied through a TestNG XML suite.
<suite name="Automation Suite">
<test name="Chrome Tests">
<parameter name="browser" value="chrome"/>
<classes>
<class name="tests.LoginTest"/>
</classes>
</test>
</suite>
The BaseTest reads the parameter and creates the appropriate WebDriver.
For larger projects, browser and application settings can be maintained in a configuration file instead of being hard-coded inside BaseTest.
browser=chrome
baseUrl=https://example.com
headless=false
A ConfigReader utility can read these values and BaseTest can use them during setup.
public class ConfigReader {
public static String getBrowser() {
return "chrome";
}
public static String getBaseUrl() {
return "https://example.com";
}
}
BaseTest can consume these configuration values.
@BeforeMethod
public void setUp() {
String browser = ConfigReader.getBrowser();
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
}
driver.manage().window().maximize();
driver.get(ConfigReader.getBaseUrl());
}
BaseTest works closely with the Page Object Model. BaseTest manages the WebDriver lifecycle, while page classes manage page-specific locators and actions. :contentReference[oaicite:1]{index=1}
BaseTest
|
+-- WebDriver
|
+-- Setup / Teardown
|
+-- LoginTest
|
+-- LoginPage
|
+-- Locators
+-- Actions
This separation makes the framework easier to understand and maintain.
public class LoginPage {
private WebDriver driver;
private By username =
By.id("username");
private By password =
By.id("password");
private By loginButton =
By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(
String user,
String pass) {
driver.findElement(username)
.sendKeys(user);
driver.findElement(password)
.sendKeys(pass);
driver.findElement(loginButton)
.click();
}
}
The test class can use the WebDriver inherited from BaseTest.
public class LoginTest extends BaseTest {
@Test
public void validLoginTest() {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
"testuser",
"password"
);
}
}
BaseTest should generally manage the test environment, while assertions should remain in the test or appropriate validation layer.
@Test
public void verifyTitle() {
driver.get("https://example.com");
String actualTitle =
driver.getTitle();
Assert.assertEquals(
actualTitle,
"Example Domain"
);
}
This separation prevents BaseTest from becoming overloaded with application-specific validations.
Test data should normally remain separate from BaseTest. Data Providers, Excel files, JSON files, databases, or configuration utilities can supply test data.
BaseTest
|
+-- Browser Lifecycle
DataProvider
|
+-- Test Data
Test Class
|
+-- Test Scenario
Page Object
|
+-- Page Actions
BaseTest can be combined with TestNG DataProvider for data-driven Selenium testing.
public class LoginTest extends BaseTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
driver.get(
"https://example.com/login"
);
System.out.println(username);
}
}
BaseTest or a TestNG listener can participate in screenshot handling when a test fails.
public void takeScreenshot(String testName) {
TakesScreenshot screenshot =
(TakesScreenshot) driver;
File source =
screenshot.getScreenshotAs(
OutputType.FILE
);
// Save the screenshot to the
// framework's screenshot directory.
}
In larger frameworks, screenshot capture is often implemented through a TestNG listener so that failure handling remains separate from the basic browser lifecycle.
Listeners can monitor test execution events such as test start, success, failure, and skipped tests. BaseTest can expose the WebDriver needed by a listener for screenshot capture.
BaseTest
|
+-- WebDriver
|
+-- Test Lifecycle
|
v
TestNG Listener
|
+-----+-----+
| |
Success Failure
|
v
Screenshot
|
v
Report
A reusable BaseTest can be integrated with reporting utilities. The test lifecycle can provide information needed by reporting components.
Test Execution
|
v
BaseTest
|
v
Test Method
|
v
Pass / Fail
|
v
Listener
|
v
Report
For production frameworks, reporting is generally handled by dedicated listeners or reporting utilities rather than putting extensive reporting code directly inside BaseTest.
Wait management can be centralized through a utility or helper rather than creating waits repeatedly inside test classes.
public WebDriverWait getWait() {
return new WebDriverWait(
driver,
Duration.ofSeconds(10)
);
}
A test or Page Object can use the common wait configuration.
A scalable automation framework should avoid putting every framework feature into BaseTest. Instead, BaseTest should coordinate reusable components.
BaseTest
|
+-- DriverFactory
|
+-- ConfigReader
|
+-- WaitUtils
|
+-- ScreenshotUtils
|
+-- Logger
|
+-- Test Listener
|
+-- Page Objects
|
+-- Test Classes
This keeps BaseTest focused and prevents it from becoming a large class containing unrelated responsibilities.
| BaseTest | DriverFactory |
|---|---|
| Manages test lifecycle | Creates WebDriver instances |
| Runs setup and teardown | Contains browser creation logic |
| Provides driver to tests | Can support multiple browsers |
| Coordinates framework setup | Focuses on driver creation |
Separating these responsibilities is useful as the automation framework becomes larger.
public class DriverFactory {
public static WebDriver createDriver(
String browser) {
if (browser.equalsIgnoreCase("chrome")) {
return new ChromeDriver();
}
if (browser.equalsIgnoreCase("firefox")) {
return new FirefoxDriver();
}
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
BaseTest can then use the factory.
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setUp() {
driver =
DriverFactory.createDriver("chrome");
driver.manage().window().maximize();
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
A browser-independent framework can use a browser parameter and DriverFactory together.
@Parameters("browser")
@BeforeMethod
public void setUp(
@Optional("chrome") String browser) {
driver =
DriverFactory.createDriver(browser);
driver.manage().window().maximize();
}
This design keeps browser-specific creation logic outside the BaseTest.
When tests execute in parallel, a shared WebDriver instance can cause test interference. A common approach is to associate a separate WebDriver instance with each execution thread.
Parallel Test Execution
Thread 1
|
+-- WebDriver 1
|
+-- LoginTest
Thread 2
|
+-- WebDriver 2
|
+-- SearchTest
Thread 3
|
+-- WebDriver 3
|
+-- CheckoutTest
For parallel frameworks, ThreadLocal<WebDriver> is commonly used to isolate driver instances between threads. :contentReference[oaicite:2]{index=2}
public class BaseTest {
private static final
ThreadLocal<WebDriver> driver =
new ThreadLocal<>();
@BeforeMethod
public void setUp() {
driver.set(new ChromeDriver());
getDriver()
.manage()
.window()
.maximize();
}
protected WebDriver getDriver() {
return driver.get();
}
@AfterMethod
public void tearDown() {
if (getDriver() != null) {
getDriver().quit();
driver.remove();
}
}
}
The important idea is that each thread gets its own WebDriver instance rather than sharing one browser session.
| Shared Driver | ThreadLocal Driver |
|---|---|
| Multiple tests may use the same browser | Each thread can have its own browser |
| Can cause test interference | Provides thread isolation |
| Difficult for parallel execution | Better suited to parallel execution |
| Risk of race conditions | Reduces shared-driver conflicts |
BaseTest can configure headless execution when browser UI is not required.
ChromeOptions options =
new ChromeOptions();
options.addArguments("--headless=new");
driver = new ChromeDriver(options);
Headless execution can be useful in CI/CD environments, provided the application and tests behave correctly in headless mode.
A BaseTest can initialize different environments such as QA, staging, and other test environments.
environment=qa
baseUrl=https://qa.example.com
The framework can load the appropriate URL before each test.
driver.get(ConfigReader.getBaseUrl());@Parameters("environment")
@BeforeMethod
public void setUp(
@Optional("qa") String environment) {
String url;
if (environment.equalsIgnoreCase("qa")) {
url = "https://qa.example.com";
} else if (
environment.equalsIgnoreCase("stage")) {
url = "https://stage.example.com";
} else {
throw new IllegalArgumentException(
"Unsupported environment: " + environment
);
}
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get(url);
}
Browser cleanup is one of the most important responsibilities of a BaseTest.
@AfterMethod(alwaysRun = true)
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
Using alwaysRun = true can help ensure cleanup is attempted even when test setup or execution encounters a failure.
A good BaseTest should help maintain test independence. A test should not depend on the browser state left behind by another test.
Test 1
|
+-- New Browser
+-- Execute
+-- Close Browser
Test 2
|
+-- New Browser
+-- Execute
+-- Close Browser
This provides a clean starting state for each test method.
@BeforeClass executes before the first test method in a class. It can be used when a browser session is intentionally shared across test methods, although this should be designed carefully because shared state can reduce test independence.
@BeforeClass
public void setUpClass() {
driver = new ChromeDriver();
}
For most independent Selenium tests, @BeforeMethod and @AfterMethod provide clearer isolation.
| Feature | @BeforeMethod | @BeforeClass |
|---|---|---|
| Execution | Before each test method | Before the first test method in a class |
| Browser isolation | Better for independent tests | May share browser state |
| Common use | Fresh browser setup | Class-level setup |
| Cleanup pairing | @AfterMethod | @AfterClass |
@BeforeSuite executes before the entire TestNG suite. It is more appropriate for suite-level initialization than browser creation.
@BeforeSuite
public void beforeSuite() {
System.out.println(
"Starting automation suite"
);
}
For example, suite-level setup could initialize shared configuration or logging.
BaseTest should contain common framework behavior rather than every possible automation operation.
Avoid placing the following unnecessarily inside BaseTest:
These responsibilities should be moved into Page Objects, test classes, utilities, Data Providers, or dedicated framework components.
| Responsibility | Suitable Location |
|---|---|
| WebDriver lifecycle | BaseTest / DriverFactory |
| Browser creation | DriverFactory |
| Page locators | Page Classes |
| Test scenario | Test Classes |
| Test data | DataProvider / Test Data utilities |
| Configuration | ConfigReader |
| Reports | Reporting utility / Listener |
| Screenshots | Screenshot utility / Listener |
| Logging | Logger utility |
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod(alwaysRun = true)
public void setUp() {
driver = new ChromeDriver();
driver.manage()
.window()
.maximize();
driver.get(
"https://example.com"
);
}
@AfterMethod(alwaysRun = true)
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
import org.testng.Assert;
import org.testng.annotations.Test;
public class HomePageTest extends BaseTest {
@Test
public void verifyHomePageTitle() {
String title =
driver.getTitle();
Assert.assertTrue(
title.length() > 0,
"Page title should not be empty"
);
}
@Test
public void verifyHomePageUrl() {
String url =
driver.getCurrentUrl();
Assert.assertTrue(
url.contains("example.com"),
"URL should contain expected domain"
);
}
}
BaseTest
|
+-- Creates WebDriver
|
+-- Opens Application
|
v
LoginTest
|
v
LoginPage
|
+-- Enter Username
+-- Enter Password
+-- Click Login
|
v
DashboardPage
|
+-- Verify Dashboard
|
v
BaseTest
|
+-- Close WebDriver
src
|-- test
| |-- java
| |-- base
| | |-- BaseTest.java
| |
| |-- pages
| | |-- LoginPage.java
| | |-- HomePage.java
| | |-- DashboardPage.java
| |
| |-- tests
| | |-- LoginTest.java
| | |-- SearchTest.java
| | |-- CheckoutTest.java
| |
| |-- utilities
| | |-- DriverFactory.java
| | |-- ConfigReader.java
| | |-- WaitUtils.java
| | |-- ScreenshotUtils.java
| |
| |-- listeners
| |-- TestListener.java
|
|-- resources
| |-- config.properties
| |-- testdata
|
|-- testng.xml
|-- pom.xml
In a larger framework, BaseTest acts as one layer of the overall architecture rather than containing every framework feature.
TestNG
|
v
BaseTest
|
+---------+---------+
| | |
v v v
Driver Config Listener
Factory Reader
|
v
WebDriver
|
v
Page Objects
|
v
Test Classes
|
v
Assertions
|
v
Reports
BaseTest works normally when Selenium and TestNG are managed through Maven.
mvn testThe Maven build can execute TestNG tests, while BaseTest automatically performs the required browser setup and cleanup.
BaseTest is particularly useful in CI/CD because browser initialization and cleanup can be standardized for every automated test.
Developer Commit
|
v
CI/CD Pipeline
|
v
Maven Build
|
v
TestNG
|
v
BaseTest
|
v
WebDriver
|
v
Test Execution
|
v
Reports / Screenshots
Environment-specific values such as browser, base URL, headless mode, or remote execution settings can be supplied through configuration or pipeline parameters.
When Selenium Grid or another remote WebDriver service is used, BaseTest or DriverFactory can create a remote WebDriver instead of a local browser.
BaseTest
|
v
DriverFactory
|
+-- Local Chrome
|
+-- Local Firefox
|
+-- Remote Chrome
|
+-- Remote Firefox
|
v
WebDriver
This allows the test classes to remain mostly independent of how the browser is created.
URL gridUrl =
new URL("http://localhost:4444");
ChromeOptions options =
new ChromeOptions();
driver =
new RemoteWebDriver(
gridUrl,
options
);
The exact Grid URL and capabilities depend on the Selenium Grid or remote browser infrastructure being used.
A common mistake is creating another WebDriver inside the test class even though BaseTest already provides one.
Incorrect:
public class LoginTest extends BaseTest {
@Test
public void loginTest() {
WebDriver driver =
new ChromeDriver();
driver.get(
"https://example.com"
);
}
}
Preferred:
public class LoginTest extends BaseTest {
@Test
public void loginTest() {
driver.get(
"https://example.com"
);
}
}
If the browser is not closed after execution, multiple browser sessions can remain open and consume system resources.
Use a cleanup method:
@AfterMethod(alwaysRun = true)
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
Using a single shared WebDriver instance for multiple parallel test threads can result in one test interacting with the browser state of another test.
For parallel execution, use an appropriate driver-management strategy such as ThreadLocal.
Thread 1 -> Driver 1
Thread 2 -> Driver 2
Thread 3 -> Driver 3
| BaseTest | Test Class |
|---|---|
| Common framework setup | Specific test scenario |
| WebDriver lifecycle | Test actions |
| Browser configuration | Assertions |
| Common cleanup | Business validation |
| Reusable functionality | Scenario-specific logic |
| BaseTest | Page Class |
|---|---|
| Manages test environment | Represents a web page |
| Creates WebDriver | Stores page locators |
| Handles setup and teardown | Contains page actions |
| Common to many tests | Specific to a page/component |
| Does not normally contain page locators | Contains page locators |
| BaseTest | Utility Class |
|---|---|
| Test lifecycle | Reusable helper operation |
| WebDriver setup | Configuration reading |
| WebDriver cleanup | Screenshot handling |
| Test environment coordination | Wait/helper functions |
Consider a Selenium automation framework for an e-commerce application.
BaseTest
|
+-- Start Chrome
+-- Maximize Window
+-- Open Application
+-- Close Browser
|
v
LoginTest
|
+-- Login
|
v
SearchTest
|
+-- Search Product
|
v
ProductTest
|
+-- Verify Product
|
v
CheckoutTest
|
+-- Complete Checkout
All tests reuse the browser lifecycle supplied by BaseTest.
public class BaseTest {
protected WebDriver driver;
@BeforeMethod(alwaysRun = true)
public void setUp() {
driver = new ChromeDriver();
driver.manage()
.window()
.maximize();
driver.get(
"https://example.com"
);
}
@AfterMethod(alwaysRun = true)
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
public class LoginTest extends BaseTest {
@Test
public void validLoginTest() {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
"testuser",
"password"
);
Assert.assertTrue(
driver.getTitle()
.contains("Dashboard")
);
}
}
BaseTest
|
+------------+------------+
| | |
v v v
Driver Config Lifecycle
Factory Reader Methods
| | |
+------------+------------+
|
v
WebDriver
|
v
Page Objects
|
v
Test Classes
|
v
Assertions
|
v
Reports / Screenshots
BaseTest is a reusable parent class that contains common automation setup and teardown functionality used by multiple test classes.
It reduces duplicate WebDriver setup and cleanup code and provides a consistent test lifecycle.
@BeforeMethod and @AfterMethod are commonly used for per-test browser setup and cleanup. Other lifecycle annotations can also be used depending on the framework design.
Protected access allows child test classes to use the WebDriver inherited from BaseTest.
driver.quit() ends the WebDriver session and closes the associated browser windows.
Yes. BaseTest can provide the WebDriver while Page Object classes manage page-specific locators and actions.
Yes. Browser selection can be implemented using TestNG parameters, configuration, and a DriverFactory.
Yes. For parallel execution, driver management must be thread-safe. ThreadLocal WebDriver is one common approach.
Generally no. Page locators should be maintained inside the corresponding Page Object classes.
Generally no. Test data should be managed through Data Providers, external files, databases, or dedicated test-data utilities.
BaseTest manages test lifecycle and framework setup, while DriverFactory focuses on creating WebDriver instances.
It provides a centralized and reusable foundation for common test infrastructure.
Yes. Browser, environment, headless mode, and other configuration values can be supplied through TestNG parameters.
Keeping business logic outside BaseTest maintains separation of responsibilities and makes the framework easier to maintain.
BaseTest can expose the WebDriver to a screenshot utility or listener that captures screenshots during failures.
Reporting can be integrated through TestNG listeners or dedicated reporting utilities that observe test execution results.
Browser sessions may remain open and consume system resources, potentially affecting later tests and the execution environment.
Independent tests reduce dependencies on previous test state and make failures easier to reproduce and diagnose.
Yes. An abstract BaseTest can be used when it is intended only as a parent class and should not itself be instantiated as a test class.
The main purpose is to centralize reusable test infrastructure such as WebDriver lifecycle management while keeping individual test classes focused on test scenarios.
| Concept | Purpose |
|---|---|
| BaseTest | Reusable parent test class |
| WebDriver | Controls the browser |
| @BeforeMethod | Runs setup before a test method |
| @AfterMethod | Runs cleanup after a test method |
| protected driver | Allows child tests to access WebDriver |
| DriverFactory | Centralizes WebDriver creation |
| ConfigReader | Reads framework configuration |
| Page Object | Stores page locators and actions |
| DataProvider | Supplies test data |
| Listener | Monitors test execution events |
| ThreadLocal | Provides thread-specific driver storage |
BaseTest is an important architectural component of a Selenium TestNG automation framework. It centralizes common test setup and teardown operations so that individual test classes do not need to duplicate WebDriver initialization and browser cleanup.
A typical BaseTest uses TestNG lifecycle annotations such as @BeforeMethod and @AfterMethod. The WebDriver is commonly exposed to child test classes through protected access or a controlled getter method.
For larger automation frameworks, BaseTest can work together with DriverFactory, ConfigReader, Page Object Model, Data Providers, TestNG listeners, screenshot utilities, reporting tools, Maven, Selenium Grid, and CI/CD pipelines.
The most important design principle is to keep BaseTest focused on reusable framework infrastructure. Page-specific actions should remain in Page Objects, test scenarios should remain in test classes, and test data should remain in dedicated data sources or Data Providers.
Learn more about Selenium automation, TestNG, Page Object Model, and framework development:
Final Takeaway: A well-designed BaseTest provides a reusable foundation for Selenium automation by centralizing WebDriver lifecycle management, browser configuration, and common test infrastructure while allowing individual test classes and Page Objects to remain clean, focused, and maintainable.
